gc: assert the positive direction of arena-growth pacing recording, on one shared accessor (#7737 item 2) - #7752
Conversation
|
Warning Review limit reached
Next review available in: 8 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (2)
📝 WalkthroughWalkthroughMajor-GC pacing now uses a shared arena-usage accessor for escalation and pre-cycle recording. Test-only overrides support deterministic checks for positive readings, predicate agreement, and inclusive floor behavior. ChangesPositive pacing recording
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related issues
Possibly related PRs
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@crates/perry-runtime/src/gc/policy.rs`:
- Around line 1591-1619: The escalation path currently samples arena usage
twice, allowing the recorded value to differ from the value used for the
decision. In crates/perry-runtime/src/gc/policy.rs:1591-1619, update
note_full_cycle_started to accept the captured arena-usage value; in
crates/perry-runtime/src/gc/policy.rs:2757-2757, have
arena_growth_full_escalation_due capture pacing_arena_in_use_bytes() once and
pass that same value to both the threshold comparison and
note_full_cycle_started.
In `@crates/perry-runtime/src/gc/tests/triggers.rs`:
- Around line 819-820: In the pacing-floor tests using major_pacing_config(),
update crates/perry-runtime/src/gc/tests/triggers.rs lines 819-820 and 870-871
to compute floor-plus-one and floor-plus-over with saturating arithmetic or
explicit maximum handling. Adjust the associated assertions so a reading equal
to the floor is accepted when usize::MAX prevents any larger value.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: ee29fa40-738b-4cda-808e-635aa0b28570
📒 Files selected for processing (3)
changelog.d/7752-positive-pacing-recording-test.mdcrates/perry-runtime/src/gc/policy.rscrates/perry-runtime/src/gc/tests/triggers.rs
| GC_FULL_CYCLE_PRE_IN_USE_BYTES.with(|bytes| bytes.set(pacing_arena_in_use_bytes())); | ||
| } | ||
|
|
||
| /// The arena reading BOTH halves of arena-growth pacing must use: the | ||
| /// escalation predicate's comparison against the boundary, and the pre-full | ||
| /// reading `note_full_cycle_started` records for `update_major_pacing_backoff` | ||
| /// to price the result against. | ||
| /// | ||
| /// `update_major_pacing_backoff`'s doc already says these are "deliberately | ||
| /// measured on the SAME metric ... so the two cannot disagree about whether a | ||
| /// full helped". Reading `arena_in_use_bytes()` twice made that a convention; | ||
| /// one accessor makes it structural (#7737). | ||
| /// | ||
| /// It is also the injection point the positive-direction test needs. Forcing a | ||
| /// `true` verdict from the REAL predicate otherwise requires an arena above | ||
| /// `PERRY_GC_MAJOR_PACING_FLOOR_MB` (32 MB by default), and the floor cannot be | ||
| /// lowered per-test: `major_pacing_config` is a process-wide `OnceLock`, so an | ||
| /// env var only takes effect if this test happens to run first. A 32 MB live | ||
| /// heap in a unit test is what `major_pacing_escalation_threshold_for` was | ||
| /// factored out to avoid, so the seam goes here instead — `#[cfg(test)]`, so it | ||
| /// compiles out of every shipping build and is not a mode anything can be | ||
| /// configured into (CLAUDE.md's GC knob kill-policy is about runtime knobs; | ||
| /// this is not one). | ||
| fn pacing_arena_in_use_bytes() -> usize { | ||
| #[cfg(test)] | ||
| if let Some(bytes) = TEST_PACING_ARENA_IN_USE.with(|cell| cell.get()) { | ||
| return bytes; | ||
| } | ||
| crate::arena::arena_in_use_bytes() |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Capture one arena reading for each escalation.
arena_growth_full_escalation_due() reads pacing_arena_in_use_bytes() for the predicate, then note_full_cycle_started() reads it again. In shipping builds, these are separate arena_in_use_bytes() samples. The recorded value can differ from the value that caused escalation.
Capture the value in arena_growth_full_escalation_due(). Pass it to both the predicate and note_full_cycle_started(). The fixed test override currently hides this two-read gap.
crates/perry-runtime/src/gc/policy.rs#L1591-L1619: makenote_full_cycle_startedaccept the captured value.crates/perry-runtime/src/gc/policy.rs#L2757-L2757: compare the captured value with the threshold.
📍 Affects 1 file
crates/perry-runtime/src/gc/policy.rs#L1591-L1619(this comment)crates/perry-runtime/src/gc/policy.rs#L2757-L2757
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@crates/perry-runtime/src/gc/policy.rs` around lines 1591 - 1619, The
escalation path currently samples arena usage twice, allowing the recorded value
to differ from the value used for the decision. In
crates/perry-runtime/src/gc/policy.rs:1591-1619, update note_full_cycle_started
to accept the captured arena-usage value; in
crates/perry-runtime/src/gc/policy.rs:2757-2757, have
arena_growth_full_escalation_due capture pacing_arena_in_use_bytes() once and
pass that same value to both the threshold comparison and
note_full_cycle_started.
| let reading = floor_bytes + 1; | ||
| let previous_reading = test_set_pacing_arena_in_use(Some(reading)); |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win
Prevent overflow for a maximum configured pacing floor.
major_pacing_config() can produce usize::MAX after its saturating conversion. Both additions then overflow in debug test builds when PERRY_GC_MAJOR_PACING_FLOOR_MB is configured to that value.
Use saturating_add or handle the maximum floor explicitly. Update the assertions to allow a reading at the floor when no larger value exists.
crates/perry-runtime/src/gc/tests/triggers.rs#L819-L820: avoidfloor_bytes + 1.crates/perry-runtime/src/gc/tests/triggers.rs#L870-L871: avoidfloor_bytes + over.
📍 Affects 1 file
crates/perry-runtime/src/gc/tests/triggers.rs#L819-L820(this comment)crates/perry-runtime/src/gc/tests/triggers.rs#L870-L871
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@crates/perry-runtime/src/gc/tests/triggers.rs` around lines 819 - 820, In the
pacing-floor tests using major_pacing_config(), update
crates/perry-runtime/src/gc/tests/triggers.rs lines 819-820 and 870-871 to
compute floor-plus-one and floor-plus-over with saturating arithmetic or
explicit maximum handling. Adjust the associated assertions so a reading equal
to the floor is accepted when usize::MAX prevents any larger value.
…n one shared accessor (#7737)
58cca84 to
493a409
Compare
Merging as v0.5.1440I filed item 2, so I checked this one harder than usual — and the load-bearing claim holds under my own hands. The sabotage, re-run here
That last cell is the whole argument: the negative-only test cannot distinguish "declined correctly" from "the recording never ran", because both produce (One correction to my own process: my first run of this sabotage showed "4 passed" and no failures, and I nearly recorded it as not reproducing. I had filtered on The accessor is the better half of this PR
Routing both through Why it wasn't testable before, recorded properlyThe explanation is worth keeping: the boundary is
ScopeCorrectly stated as not closing #7737: item 1 landed in #7740, item 3 needs the pinned bench host, item 4 is a maintainer action. Leaving the issue open with two items outstanding is the honest bookkeeping. Gates 21/21. |
1 participant
Addresses item 2 of #7737 ("No positive-direction test for the recording"). Item 1 landed in #7740; item 4 is a maintainer action; item 3 needs the pinned bench host and is left open — so this does not close the issue.
The gap
declining_to_escalate_records_no_pre_full_readingproves only the negative: a declined escalation leavespre_in_use == 0. Nothing asserted that atrueverdict from the realarena_growth_full_escalation_due()— not thetest_note_full_cycle_reclaimedbypass, which sets the reading itself — leaves a non-zero one behind.A negative-only test cannot tell "declined correctly" from "the recording never ran". Both produce
0. That is exactly the first-cut bug #7733's own changelog describes: the recording wired at the wrong call sites,update_major_pacing_backoffreturning early on a zero pre-reading, and every test still green.Why it wasn't already there, and what I did instead
The issue says forcing
due=true"needs control overarena_in_use_bytes(), which isn't mockable today". Confirmed, and the reason is worth recording: the boundary ismax(floor, baseline × growth + 1), and the floor always dominates from below, so no amount of baseline manipulation gets the threshold under it.PERRY_GC_MAJOR_PACING_FLOOR_MBcan't help either —major_pacing_configis a process-wideOnceLock, so an env var only takes effect if this test happens to run first.That leaves a 32 MB live heap, which is precisely what
major_pacing_escalation_threshold_forwas factored out to avoid ("unit-testable without a 32 MB live heap").So the reading is injected, through a new
pacing_arena_in_use_bytes()— the one accessor both the escalation predicate andnote_full_cycle_startednow use.The accessor is the more interesting half
update_major_pacing_backoff's doc already claims:But both sites called
arena_in_use_bytes()independently. The guarantee was a convention two call sites happened to honour, not a structure — the same shape as the snapshot-vs-predicate divergence #7733 fixed by collapsing two formulas into one. Routing an injected reading in and requiring the same value back out is what makes it checkable.The override is
#[cfg(test)]: it compiles out of every shipping build, so it is not a runtime knob and the GC knob kill-policy doesn't apply.Tests, and proof they can fail
Three, all deterministic (thread-local, no timing, no allocation):
escalating_records_the_pre_full_arena_reading— the item-2 ask.the_recorded_reading_is_the_one_the_predicate_decided_on— agreement across several readings.the_floor_is_inclusive_and_below_it_declines—floor - 1declines and records nothing; exactlyfloorescalates. (The>=on the floor is whymajor_pacing_escalation_threshold_foradds its+1to the growth boundary and not to the floor.)Both sabotage arms were run:
note_full_cycle_startedat a second, independentarena_in_use_bytes()(metric drift)And in both arms the pre-existing negative test still passed — so the gap this PR closes is demonstrated, not merely asserted.
Validation
cargo test -p perry-runtime --lib: 1991 passed, 0 failed.cargo fmt --all --check,scripts/check_file_size.sh: clean.One thing worth flagging for #7365 rather than this PR: across four repeat runs of the full suite under CPU load I saw 0–2 failures per run, always from
promise::keyed_table::tests::{settling_many_keys,draining_a_heavily_populated_key_ahead_of_another}_is_not_quadraticand oncegc::tests::inline_generation_gate_contract::sabotaged_parent_gate_strands_a_young_child_the_shipped_gate_keeps. Those are wall-clock-ratio assertions, which is a plausible mechanism for "#7365: fails a different number of tests on every run". None of the three is touched by this PR, and my three new tests never appeared in any run.No version bump (maintainer bumps at merge).
Summary by CodeRabbit
Bug Fixes
Tests